在前次內容中，我們討論了前端與後端的主要語言，這篇就會藉此延伸，討論其他的議題。
現在我們已經討論過前端和後端，還有一種類型的開發者你應該有聽過，那就是 全端開發者（Full-stack Developers）。通常全端開發者被稱為開發領域的「萬能人才」，因為他們同時負責應用程式的前端和後端開發，通常能夠處理大部份的開發需求。
在大多數情況下，全端開發者會深入學習某個特定領域的專業知識，例如資料庫管理或 UI/UX。這樣，他們能夠成為更具專業性的「T 型開發者」，既涵蓋前後端的工作，又不會流於僅是泛泛而談 [1]。儘管全端開發者需求很大，但他們在某些特定工具方面的專業知識，通常就不具備相比於專項開發者的。這就像是田徑十項全能的世界紀錄保持者 Kévin Mayer，他在 2018 年以總分 9155 分打破世界紀錄時，跑出 100m 的成績為 10’55 [2]，但眾所周知，100m 短跑的世界紀錄是由 Usain Bolt 在 2009 年於大邱世錦賽所樹立的 9’58 障礙。[3]
這我認為需要從就業環境來討論了，注意以下是從我個人觀點出發，我們分別以美國與台灣為例：
在美國的全端工程師需求一直都很高，尤其是一些新創企業，因為他們需要一個可以快速開發產品的人員，全端工程師這種具備「三頭六臂」就很適合面對這些開發需求，尤其是那些資源很有限的團隊，這些工程師需要參與整個計畫從 初始設計 到 部屬應用 的所有環節。而2023 年全端開發者的年薪平均在 US$90,000 至 US$120,000 之間，頂尖的技術公司如 Google、Amazon 或 Facebook 等的大型科技公司甚至會提供更高的薪資，年薪可達 US$150,000 以上。[4][5]
然而，相比於專業化的前端或後端開發者，全端開發者著重在技術廣度與管理能力的發展上，他的薪資「可能」稍低於那些在某個領域具備深厚專業知識的開發者，例如純 ML 工程師這種起跳門檻相對高的人員。但其實不是全端開發者發展容易觸頂，而是一些全端工程師會逐漸向技術管理者或產品經理轉型，因為他們能夠理解項目的全貌，並且具備整合各方需求的能力。[6]
相比美國，台灣的全端開發者薪資普遍較低。根據 2023 年的統計資料，台灣全端開發者的年薪通常在新台幣 60 萬至 100 萬之間（US$20,000 至 US$35,000），有些會到 200 萬（US$65,000）。[7] 而頂尖的科技公司或是外商提供的薪資會更高，但仍遠低於美國。台灣的薪資差距也反映了市場規模較小，且多數公司偏向快速推出產品，因此使得全端開發者較少有機會深入研究某一領域，從而在技術深度上受到限制，因此專業能力往往不及美國。[8] 此外，隨著技術需求的增多，部分全端開發者可能會面臨技術更新過快、專業技術難以保持的壓力。因此，在台灣的全端開發者在新創公司或小型企業的管理職位上，可能會有較好的發展，甚至有機會轉為創業。
或許你可能會問：「那不然去美國就好了阿～幹麻留在台灣？」針對這題，我們首先就要先問哪位美國雇主願意提供你 H1-B / EB-2 Visa Sponsorship？ [9][10]除非你持有美國綠卡或護照，那就是另一個故事了～
離題了，我們回來討論為何要分前後端。
因為在早期的網頁開發時期，開發者的工作相對簡單，大多數網站都是由簡單的靜態 HTML 頁面所組成，通常這也代表開發者既要負責設計頁面，也要處理伺服器端的資料。因為前端和後端之間的界限不明顯，因此這種 「全端開發」 的模式在那個時代很常見。
但隨著 WWW 的應用的複雜度增加，且 CSS 與 JavaScript 相繼問世、瀏覽器功能逐漸強大（那年 IE 改版都伴隨一堆新功能 [11]），網站開始變得更加動態。使用者不再只需要靜態的網頁呈現，而是希望能夠與網站互動，例如網路購物、部落格留言等，這些需求需要有專門的人去研究如何實作。前段開發者開始需要逐漸專注在「如何呈現網頁的動態內容」，並確保這些功能可以在不同的瀏覽器中被實作出來。而後端開發者就著重在資料庫、伺服器、以及程式語言背後的邏輯。由於資訊交換量逐年在提升，他們總是在思考「如何提升資料處理效率」以及「如何維持伺服器穩定運作」（想想當年 PTT 伺服器當機都導致網路上哀鴻遍野）。而近年來的網頁開發更加強調資安、用戶認證、以及資源管理，因此你會發現，一個人實在很難對每個領域都這麼瞭若指掌，因此「分工」就是一個重要的議題。
綜上所述，開發者不再需要掌握所有技術，反而專注於某一領域的深度研究。而你可能會好奇，我們這樣拆開前端和後端，那這之間是如何協作的？是否有一個統一規範？其實是有的，我們通常是通過 API（Application Interface，應用程式介面） 進行實作。可以想像 API 就像是餐廳的服務生，他要負責把 User（顧客）透過 Client（菜單）把需求送至對應的 Server（廚房）。
在 1990 年代末，隨著 Web 的快速發展，傳統的通信協定如 SOAP（Simple Object Access Protocol）和 RPC（Remote Procedure Call）已經逐漸無法滿足網路上的大規模需求，因為這些通常需要撰寫視覺上較為複雜的 XML 文件並遵循繁瑣的語法規範，導致開發和維護成本非常高。[12]
在 2000 年，由 Roy Fielding 在他著名的博士論文 "Architectural Styles and the Design of Network-based Software Architectures" 中提出了 REST 架構風格，並介紹如何藉由 HTTP 協議的簡單方法來高效操作分佈式系統中的資源。Fielding 觀察到，Web 的成功就是基於 HTTP 協議的簡單性和通用性，而 REST 就是從中提煉出的設計原則。[13]
Sourse: https://www.youtube.com/watch?v=9OlMQpivP2Q&ab_channel=Jeva
不過，API 之間的傳遞過程並不是隨意處理的，我們會透過 HTTPS 協議進行通訊（以前是 HTTP）。就像服務生需要遵照餐廳的 SOP 進行點餐與上菜，而 API 也必須遵循一套 SOP 來發送和接收數據。這些標準讓前端和後端可以順利協作，而不會發生「點單不明確」或「誤送菜肴」的情況。
Representation of Frontend, Backend, Fullstack, and API
Source: https://pikabu.ru/tag/Backend,Frontend/hot?page=6
而具體來說，API 是透過 TCP/IP 協議進行通訊的，這是一種較為底層的網絡傳輸協議，用來確保數據能夠從前端安全地送達後端並獲得正確的回應。若這個服務生可以統一處理所有店裡的資料交換需求，那這就是 RESTful API 了。你可能會好奇 API 與 RESTful API 差在哪？簡單來說，API 是一個廣泛的概念，而 RESTful API 是一種基於 Web 所設計的 API，而後續會有一個章節專門講述網路通訊的基礎，包含 TCP/IP、Client 與 Server 等相關內容，並且透過框架與 TypeScript 實作 RESTful API。
在版本控制系統出現之前，開發者只能依靠手動儲存紀錄或備份既有專案，但顯而易見的是，每個人的命名習慣都不盡相同（如 project_v1、project_v2、project_v2_01mod … 等），這樣的純手動紀錄其實很容易出錯，而且當團隊人數增加時，團隊協作的版本控管就會成為一種挑戰。
Source: https://www.linkedin.com/pulse/differentiate-between-centralized-distributed-version-control-ejv2c
為了解決這問題，CVCS（集中式版本控制系統）因此誕生。在這系統中，所有的歷史更動紀錄都會集中在一個中央伺服器上，開發者從伺服器中下載程式碼後再進行修改，最後再將修改完的程式碼上傳回伺服器，這就是早期的版本控制系統，很大程度上解決了多人協作的問題。[14]
然而這樣的系統伴隨來的缺點就是故障問題。當遠端伺服器故障的時候，整個系統運作就會中斷；而以當時技術，如果伺服器硬碟出現故障，且又沒有硬碟的備份檔案的話，那基本上整碗壞去了。最明顯的問題就是，當團隊要同步開發 Beta 版本的系統功能時，就難以保留主要的穩定的版本，因此這些不穩定的開發進度就無法推送到主要資料庫（Repository），因此開發人員必須將它們保留在自己的電腦中，直到完全就緒才發佈為止。[14]
以上內容光是看下來，就會發現 CVCS 還是難以滿足現代的開發需求了，這因而推動了 DVCS（分散式版本控制系統）的誕生。有關 DVCS 的核心思想，就是每個開發者都有一個完整的 Repository 的副本（Mirror），這樣即便中央伺服器出現故障，開發者仍然可以在他們電腦中進行開發，並查閱歷史更改記錄。這也是現在最流行的 Git 的主架構。[15]
Git 在 2005 年由 Linux 作業系統的創始人 Linus Torvalds 所開發，而他本人曾經調侃地說：
I'm an egotistical bastard, and I name all my projects after myself. First Linux, now Git. [16]
意思是說他喜歡給自己的項目取有點自我中心的名字，因為他之前的操作系統命名為「Linux」，這是 Linus 加上 Unix 的結合，而現在這個版本控制系統叫「Git」，有多種含義且帶有諷刺的幽默感，有點像在說「令人討厭的人」或「自大的傢伙」[17]。
當時，Linux 核心開發團隊使用的是一個名為 BitKeeper 的商業版本控制系統來管理 Linux Kernel（內核）的原始碼。然而，BitKeeper 的免費授權被無預警撤回，這操作直接讓 Linux 社群陷入了困境，所以他們急需一個新的版本控制工具做為替代品。[18]
後來 Torvalds 决定自行開發一個名為 Git 的 DVCS，且還同時滿足了 Linux 社群需求。它的設計目標還包含兼容性（完全延續 BitKeeper 功能）與安全性（防止被惡意手段破壞）。當然還有很多改進的細節，可以參考這裡有更多介紹。
https://community.appsmith.com/content/blog/evolution-git-dive-tech-history
而根據 StackOverflow 在 2022 的調查中，Git 市佔率高達 93.87%，以至於隔年 StackOverflow 乾脆放棄問大家用什麼版本控制系統 [19]。這反應出「學好 Git 是相當重要的一件事情」，因為 94％ 的市占率就基本上代表現在企業都在使用 Git。那有關相關學習資源，可以參考 FreeCodeCamp 的這文章，從安裝、提交（Commit）、分支（Branch）等，都有詳細的介紹與說明，個人認為寫得蠻淺顯易懂的，推薦給大家：
https://www.freecodecamp.org/news/how-to-use-git-best-practices-for-beginners/
以上內容總結了前後端開發的分離、溝通方式、以及版本控制進行說明，並引入一些歷史。在下一篇文章中，就會從 HTML 1.0 到 5.3 的版本演變來講述 Web 的發展史，很多時候搞懂歷史背景的 Context 真的比硬幹硬背還要有效多了，因此分享給大家！
[1] https://dev.to/aellon/are-you-a-t-shaped-developer-4npk
[2] https://worldathletics.org/records/all-time-toplists/combined-events/decathlon/all/men/senior?regionType=world&windReading=regular&page=1&bestResultsOnly=false&firstDay=1900-01-01&lastDay=2024-09-13&maxResultsByCountry=all&eventId=10229629&ageCategory=senior
[3] https://worldathletics.org/records/all-time-toplists/sprints/100-metres/outdoor/men/senior
[4] https://careerfoundry.com/en/blog/web-development/full-stack-developer-salary-guide/
[5] https://www.indeed.com/cmp/Meta-dd1502f2/salaries
[6] https://www.talent.io/p/fr-articles/career-how-to-transition-from-developer-to-product-manager
[7] https://tw.alphacamp.co/blog/software-developer-salary-in-taiwan
[8] https://column.meet.jobs/taiwan-software-industry-analysis/
[9] https://www.uscis.gov/working-in-the-united-states/h-1b-specialty-occupations#:~:text=The%20application%20requires%20the%20employer/agent%20to%20attest,or%20lockout%20at%20the%20place%20of%20employment.
[10] https://www.uscis.gov/working-in-the-united-states/permanent-workers/employment-based-immigration-second-preference-eb-2
[11] https://www.makeuseof.com/internet-explorer-history/
[12] https://blog.treblle.com/from-soap-to-rest-tracing-the-history-of-apis/
[13] Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures (Doctoral dissertation, University of California, Irvine). University of California. https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
[14] https://about.gitlab.com/topics/version-control/what-is-centralized-version-control-system/
[15] https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/
[16] https://dictionary.cambridge.org/dictionary/english/git
[17] https://community.appsmith.com/content/blog/evolution-git-dive-tech-history
[18] https://www.linuxjournal.com/content/git-origin-story
[19] https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/
iThome鐵人賽
看影片追技術